stvkfandomcom-20200213-history
Vaba tarkvara ja selle arendusmudelid
Ajalugu Aastal 1997 kirjutas Eric S. Raymond "The Cathedral and the Bazaar"-i http://www.catb.org/~esr/writings/cathedral-bazaar/ . Selles raamatus eristab Raymond kahte liiki tarkvara arendust. Esimene neist on tavaline suletud lähtekoodiga tarkvara arendus. Sellised arendusmeetodid on Raymondi sõnul nagu katedraali ehitamine: keskne planeerimine, piiratud organisatsioon ning üks protsess algusest lõpuni. Teine on edasiarenev avatud lähtekoodiga arendus, mis on rohkem nagu "suur lalisev turg erinevate reglementide ja meetoditega, millest ühtne ja stabiilne süsteem võiks näiliselt kerkida vaid järjestikuste imede läbi." Viimase analoogiat võib kõrvutada avatud lähtekoodi arenduse protsessiga: osades projektides võib igaüks esitada ettepanekuid ja nende üle arutada. "Ühtsed ja stabiilsed süsteemid", mida Raymond pidevalt mainib, tulevad tihti esile just avatud lähtekoodiga tarkvara arenduse projektidest. Bar ja Fogeli järgi on erinevused kahe arendusprotsessi vahel üldiselt vigade raportite ja funktsionaalsuse päringute käsitlemise (ja loomise) vahel ning piirangutest, mille alusel programmeerijad töötavad. Suletud lähtekoodi arenduses kulutavad arendajad tihti palju aega vigade raportitele ja nende genereerimisele, samuti kõikide funktsionaalsuste soovide peale. Aega kulutatakse arendusplaanide kavandamiseks ja prioritiseerimiseks. Seega kulub rohkem aega probleemide lahendamisele, kui tõelisele programmeerimisele. Samuti peavad sellised arendusmeeskonnad tihti töötama piirangutega (nagu tähtajad, eelarve jne), mis häirivad tarkvara tehnilist külge. Avatud lähtekoodi arenduses on need probleemid lahendatud integreerides tarkvara kasutajaid arenduse protsessi või isegi lastes nendel inimestel süsteem ise ehitada. Vaba tarkvara projektide peamised tüübid (Martin) Vaba tarkvara projektid võib üldjoontes jagada järgmiselt: *'Eraldiseisvad programmid' (program) ja teegid (library). Tegemist on eraldiseisvate koodibaasidega (codebase), mis võivad, kuid ei pruugi sõltuda välistest teekidest. Näitena: Linuxi kernel *'Distributsioonid '(distribution). Distributsioon on kogum tarkvara (programmid ja teegid), mida levitatakse ühe allika kaudu. Distributsiooni komponendid on valitud selliselt, et need aitaksid täita distributsiooni eesmärke. Distributsiooni kõige levinumaks näiteks on operatsioonisüsteem. Vaba tarkvara puhul on levinuimateks distributsioonideks erinevad Linuxi distributsioonid. Linuxi distributsioonide reeglina väga lühikesed arendustsüklid (võrreldes näiteks suletud lähtekoodiga operatsioonisüsteemidega) muudab võimalikuks nende modulaarsus - iga moodul on sisuliselt omaette vaba tarkvara projekt, millel on oma arendajad (ning sageli ka oma kogukond). Neid projekte, mille töö tulemusi Linuxi distributsioonid oma koosseisus kasutavad, nimetatakse upstream ''projektideks (kood liigub eraldiseisvate programmide ja teekide kaudu "allavoolu" Linuxi distributsiooni koosseisu - selle muudab võimalikuks lähtekoodi vaba levitatavus). Seega on Linuxi distributsioonide arendajate koguarv (koos ''upstream ''projektide arendajatega) kokkuvõttes üsna suur. Näitena: Ubuntu Fedora : Näide tarkvaradistributsioonist, mis ei ole operatsioonisüsteem - WAMP Server *'Operatsioonisüsteemide arendamise projektid. 'Operatsioonisüsteemide arendamise projektid erinevad näiteks Linuxi distributsioonidest selle poolest, et terve operatsioonisüsteemi - kerneli ja teiste tuumkomponentide - lähtekood asub ühes versioonihaldussüsteemis ning seda arendavad ühed ja samad arendajad. Selline lähenemine võimaldab kogu operatsioonisüsteemi koodi tervikuna testida ja optimeerida. Samuti on kogu koodibaasi lähtekood ühesuguse stiiliga kirjutatud - sarnane muutujate nimetamise ja kommenteerimise viis kogu koodi ulatuses lihtsustab kindlasti uute projektiga liitunud arendajate koodiga tutvumist. Näitena: FreeBSD Vaba tarkvara arendusmeetodid Vaba tarkvara projektide elutsükliks on tavaliselt koskmudel, sest seal ei ole lubatud minna tagasi eelmisesse faasi. Vaba tarkvara arenduse nõuded ei ole tavaliselt enne projekti alguset kokku kogutud; pigem baseeruvad nad tarkvara varajasematest väljalasetest, nagu Robbins kirjeldab.''Robbins, J. E. (2003). Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools. Making Sense of the Bazaar: Perspectives on Open Source and Free Software, Fall 2003 Peale nõuete on tavaliselt ka vabatahtlikke töötajaid, kes on huvitatud aitamaks arendada tarkvara toodet, mis baseerub tarkvara varajastele väljalasetele. Selline võrgustiku effekt on vastavalt Abrahamssonile jt oluline, sest: "Kui see tutvustatud prototüüp kogub piisavalt tähelepanu, siis hakkab see järk-järgult ligi meelitama rohkem ja rohkem arendajaid". Siiski toovad Abrahamsson jt välja, et kogukond on väga karm ning väga sarnane suletud tarkvara ärimaailmaga: "Kui sa leiad kliendid, jääd sa ellu, klientideta sa sured". Vaba tarkvara arenduse faasid Vaba tarkvara arendust saab jagada mitmes se faasi. Siin toodud faasid pärinevad Sharmalt. Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002). A framework for creating hybrid-open source software communities. Information Systems Journal 12 (1), 7-25 Kõrvalolev diagrammil on näidatud avatud lähtekoodiga tarkvara arenduse protsessi struktuur nii arenduse faasidega, nendes sisalduvate tegevustega, kui ka nendega kaasnevate vastavate andmeelementidega. Protsessi alguses on valik, et kas hakatakse edasi arendama mõne teise, juba olemasoleva, projekti pealt või alustatakse täiesti uut projekti. Kui alustatakse täiesti uut projekti, minnakse algfaasi, teisel juhul kohe teostamise faasi. Versioonikontrollisüsteemid ja nende tähtsus vaba tarkvara projektides OSS arenduses osalejad, kes on tihti vabatahtlikud, on väga erinevates geograafilistes regioonides, seega on vaja kasutada vahendeid, mis aitaksid osalistel teha koostööd lähtekoodi arenduses. CVS (Concurrenct Version System) on ilmekas näide lähtekoodi abivahendist, mida kasutatakse OSS projektides. CVS on vaba versioonihaldustarkvara, mis süstematiseerib ja säilitab informatsiooni faili muutmise ajaloo kohta (kes tegi, mida ja millal). Lisaks kehtestab CVS faili muutmise tingimused ja jälgib nende täitmist, mis võimaldab vältida muudatuste hävimist kui ühe ja sama failiga töötab paralleelselt mitu inimest. Teiseks heaks näiteks on SVN (Subversion Control System), mis loodi selleks, et asendada CVS. Torvalds väidab siiski, et CVS-i pole võimalik õigesti teha, ning seega on SVN läbi kukkunud juba projekti definitsioonist alates. Paljud vaba tarkvara projektidest kasutavad nüüd hoopis hajusat versioonikontrolli süsteemi, mis on paremad kui tsentraliseeritud hoidlad nagu SVN ja CVS. Populaarseteks näideteks on git, mida kasutatakse Linux kerneliga, ja Mercurial, mida kasutatakse Pythoni programmeerimiskeelega. Git-i arenduse lükkas käima BitKeeperi õiguste omanik Larry McVoy, kes võttis tollal Linuxi kerneli ja muu vaba tarkvara arenduseks kasutatud BitKeeperi kasutusõiguse vaba tarkvara kommuunilt tagasi ning BK-le oli tarvis asendust - selleks asenduseks loodigi Git. Vaba tarkvara arenduseks kasutatavad suhtluskanalid Vaba tarkvara projektiga seotud arendajad ja kasutajad ei tööta tingimata projekti läheduses, seega on neil vaja mõnda elektroonilist sidevahendit. E-mail on üks kõige levinumaid suhtlusvorme vaba tarkvara arendajate ja kasutajate vahel. Tihti tehakse meililistid veendumaks, et kõik osapooled saaksid info korraga kätte. Et suhtlus oleks reaalajas, kasutavad paljud projektid kiirsuhtlust (Instant Messaging) nagu IRC (kuigi selleks on ka palju muid võimalusi). Vaba tarkvara kasutamisel esinevate probleemidega abi saamiseks on hiljuti hakatud kasutama ka veebipõhiseid foorumeid. Wikid on hakanud levima kommunikatsioonivahendina arendajatele ja kasutajatele. Siiski ei tähenda vaba tarkvara arendus ainult virtuaalset kommunikatsiooni - aktiivsematel suurematel projektidel on tihti kord või paar aastas meet-up'id, kus tehakse kokkuvõtteid, planeerimist ja mõnikord kirjutatakse ka koodi. Sellised üritused on väga vajalikud eelkõige kommuuni koos hoidmiseks ning lisaks ka projekti kokkuvõtete/planeerimise efektiivsemaks teostamiseks. Näiteid: XDC2011, Akademy (KDE), GUADEC (GNOME). Vigade jälgimine ja ülesannete nimekiri Enamik suuremahulisi projekte nõuavad veajälgimissüsteeme (tavaliselt veebi või muul viisil interneti põhine), et jälgida erinevate probleemide staatust projekti arenduses. Lihtne tekstifail ei ole piisav, sest tavaliselt on palju ühesuguseid vigu ning soov on lihtsaustada vigade aruandlust ning hooldust kasutajate ja arendajate. Mõned populaarsed veajälgimissüsteemid on: *Bugzilla http://en.wikipedia.org/wiki/Bugzilla *Mantis Bug Tracker http://en.wikipedia.org/wiki/Mantis_Bug_Tracker *Trac http://en.wikipedia.org/wiki/Trac *Request tracker http://rt.cpan.org/ *GNATS http://www.gnu.org/software/gnats/ *SourceForge http://en.wikipedia.org/wiki/SourceForge *LibreSource http://en.wikipedia.org/wiki/LibreSource *SharpForge *JIRA http://en.wikipedia.org/wiki/JIRA Kogukonna osavõtt tarkvara arendusprotsessist (Martin) Kõrvalolev pilt Software: Closed vs Open illustreerib kogukonnapoolse tagasiside võimalusi suletud lähtekoodiga Windowsi- ja avatud lähtekoodiga Linuxi maailmas. Suletud lähtekoodiga projektide puhul on ainsateks arendajateks projekti omava ettevõtte arendajad (Windowsi puhul Microsofti arendajad) ning ülejäänud kogukond on ainult tavalised kasutajad, kelle võimalus arendajatele tagasisidet anda on enamasti üsna olematu. Kasutajaid eraldab arendajatest (ja ka projekti lähtekoodist) justkui sein, millest on võimatu kasutajate poolelt läbi pääseda. Vaba tarkvara projektide puhul (näiteks erinevad Linuxi distributsioonid) on piir kasutajate ja arendajate (pildi peal nimetatud häkkeritena) vahel tavaliselt üsna hägune - piisava tahtmise korral on kõigil võimalus projekti arendamisel kaasa lüüa. Erinevalt suletud lähtekoodiga projektidest võib avatud lähtekoodiga projektide puhul olla erinevate moodulite realiseerimiseks kasutatud erinevaid programmeerimiskeeli (näiteks Linuxi distributsioonid). See toob kaasa täiendava keerukuse nii tarkvara arendamisel, hooldamisel kui ka teiste tarkvaramoodulitega integreerimisel. Samas võimaldab erinevate programmeerimiskeelte kasutamine ligi meelitada väga erineva tausta ja oskustega arendajaid. Kogukonna osavõtt tarkvara arendusprotsessist vaba tarkvara projektide korral Vaba tarkvara projektide puhul võib kogukonna (kasutajate/arendajate) osavõtt arendusprotsessist olla väga erineva ulatusega. Väga väikese kasutajate hulgaga (või ka lihtsalt väga noorel) projektil võib olla ainult üks arendaja/haldaja (maintainer), kes uut funktsionaalsust implementeerib ja leitud vigu parandab. Sellisel juhul on kasutajate peamiseks kaasaaitamise võimaluseks vigade raporteerimine ja soovitavast puuduolevast funktsionaalsusest teadaandmine (wishlist). Projekti arendajal/haldajal tuleb endast parim anda, et leitud vead parandada ja kasutajate poolt soovitud funktsionaalsus implementeerida. Ainult siis on võimalus, et projekti populaarsus kasvab ning see toob juurde uusi kasutajaid ja (mõne aja möödudes) ka arendajaid. Kui projekt on saavutanud suurema populaarsuse ja sellega on liitunud täiendavaid arendajaid (contributors)'', ''siis muutub projekti edasiste arengusuundade kindlaksmääramine keerulisemaks - rohkem arendajaid ja kasutajaid, kellel on erinevad vajadused/nõudmised. Selle tulemusena kulub projekti populaarsuse suurenedes ja keerukuse kasvades üha rohkem aega bürokraatiale - projekti tulevikku puudutavaga tegelemisele, projekti osaliste hierarhia ja vastutuste haldamisele jne. Vaba tarkvara projektide eripäraks on olemasolevate projektide koodibaasi alusel täiesti uue tarkvaratoote arendamise võimalus (tarkvaraprojekti nn fork'imine ). Ainsaks oluliseks piiranguks on sellisel juhul esialgse projekti litsentsist tuleneda võivad piirangud. Forkimise näitena võib tuua LibreOffice'i projekti algatamise, mis on väga heaks näiteks selle kohta, kuidas arendajate kogukond väljendab oma rahulolematust "võttes ohjad enda kätte" ning loob endale meelepärase tarkvaraprojekti, võttes aluseks juba olemasoleva OpenOffice'i projekti koodibaasi. ''A year after the fork: LibreOffice is growing and going strong.Ryan Paul. Ars Technica, 2011/09 Eelnev näide demonstreerib lähtekoodi vaba kättesaadavuse olulisust. Kuid ka selles aspektis võivad vaba tarkvara projektid omajagu erineda. Google'i poolt arendatav Linuxil baseeruv mobiilseadmete operatsioonisüsteem Android on näide selle kohta, kuidas piiratakse laiema kogukonna ligipääsu projekti lähtekoodile. Google kontrollib Androidi arendust suures osas ilma kogukonna kaasamiseta projekti arendusprotsessi. ''Android Open Source Project: Frequenty Asked Questions. Operatsioonisüsteemi viimase stabiilse versiooni lähtekood tehakse küll kõigile kättesaadavaks, kuid hetkel arenduses oleva versiooni lähtekood ei ole avalik ''Android Open Source Project: Android Code-Lines. - seega ei ole kogukonnal võimalust võtta osa Androidi tulevase funktsionaalsuse planeerimisest. Samuti on häiritud kõikvõimalike derivatiivsete projektide töö (näiteks CyanogenMod ). Vastupidiselt Androidile on Linuxi kerneli ja kõigi selle erinevate moodulite lähtekood kogu arendustsükli jooksul kõigile soovijatele vabalt kättesaadav ''Linuxi kerneli git repositoorium. Viited